For complex systems, such as networking equipment and the like, maintaining backward compatibility between software and firmware is difficult. In some cases, only one release, or point release, of backward compatibility is supported and great pains are taken in the system design to accomplish this. In many cases, backward compatibility is not supported at all, and software and firmware must be upgraded together. Complex upgrade procedures are often required and traffic is interrupted. Such is the case for Cisco Multiprotocol Label Switching (MPLS) networks, for example.
Upgradeable firmware has become particularly important for the next generation of switching equipment. Field programmable devices, i.e. Field Programmable Gate Arrays (FPGAs), are frequently used for network interfaces in transport equipment. Being able to upgrade the firmware in the field has become a requirement and will be commonplace as new features and bug fixes are added to the hardware.
In cases where backward compatibility is not supported, software and firmware must be upgraded together in order to make a system fully operational. For some networking equipment and the like, traffic is not interrupted by a software upgrade alone. However, a firmware upgrade will always result in a traffic interruption if a given device is in the data path. Because software upgrades operate on all equipment in a network element at the same time, firmware upgrades must also operate on all equipment in the network element concurrently. If the given devices are in the data path, the worst case scenario results in all network interfaces being out of service for the duration of the upgrade. This is highly undesirable, as the only way to maintain service is to switch all traffic to a different network element—something that is not always possible, and is never desirable. Backward compatibility solves this problem, as devices may be upgraded one at a time and traffic may be switched to protect network interfaces during the upgrade process.
Thus, backward compatibility is always desirable and complex software designs are often employed. Typically, this involves maintaining a hardware abstraction layer that may interface a new software application layer to both old and new versions of the firmware. Maintaining relationships between object and driver code for multiple firmware versions is complex and limits the number of firmware versions with which backward compatibility may be achieved. A customer will often desire an upgrade that jumps more than one release. If only one level of backward compatibility is maintained, the upgrade must be done in stages—for example, going from version 1.0 to version 3.0 may require first installing version 2.0. This makes the process long and complex, and increases the chances that something will go wrong in the network.
It is therefore desirable to have a method of maintaining backward compatibility to multiple firmware releases without making the hardware abstraction layer overly complex.